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ABSTRACT  (Continue  on  reverae  aide  It  neeeaamry  end  identity  by  block  number) 

Early  software  error  models  by  Shooman  and  Jellnski-Moranda  related  the  number 
of  errors  in  a large  software  system  to  the  rate  of  error  removal.  Expressions 
for  the  number  of  remaining  errors  as  the  software  undergoes  debugging  were 
formulated  and  additional  assumptions  were  made  to  relate  the  number  of  residual 
errors  to  the  operational  system  reliability.  One  of  the  key  assumptions  of 
the  above  models  was  that  the  sum  of  the  errors  removed  and  those  remaining  in 
the  program  is  constant. 

\ (cont'd) 


FORM 
I JAN  71 


EDITION  OP  I NOV  *S  it  OBSOLETE 


UNCLASSIFIED 


security  classification  op  this  page  rm>.n  dm*  Ehimmjj 


A3 


SECUNITV  CLASSIFICATION  OF  THIS  PAOEfWnn  DmU  Entered; 


his  report  adds  a major  refinement  to  the  above  models  by  introducing  the 
possibility  of  error  generation  during  debugging.  In  this  refinement  the 
error  generation  terms  are  modeled  in  several  different  ways:  proportional 

to  the  number  of  detected  errors,  corrected  errors,  the  number  of  remaining 
errors,  or  some  function  of  these  effects.  The  correction  rate  is  assumed 
to  be  a function  of  the  manpower  deployed  on  the  project,  thus  permitting  the 
use  of  the  model  to  investigate  optimum  manpower  deployment  strategies.  The 
effects  on  the  economics  of  debugging  due  to  error  growth  have  also  been 
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ABSTRACT 


Several  previous  models  in  the  literature  have  discussed  how  the  num- 
ber of  errors  in  a large  software  system  is  related  to  the  rate  of  error  re-- 
moval.  In  1971  Shooman,  and  Jelinski  and  Moranda  proposed  similar  Prob- 
abilistic Models  for  the  removal  rate  of  software  errors  during  software 
development.  The  models  proposed  by  Shooman  were  based  on  error  data 
on  7 different  large  operating  systems  and  application  programs  and  col- 
lected by  Hesse,  and  these  models  also  fit  the  data  of  Akiyama  which  was 
collected  on  small  programs.  Expressions  for  the  number  of  remaining 
errors  as  the  software  undergoes  debugging  were  formulated  and  additional 
assumptions  were  made  to  relate  the  number  of  residual  errors  to  the  op- 
erational system  reliability. 

One  of  the  key  assumptions  in  the  above  models  was  that  the  sum  of  the 
errors  removed  and  those  remaining  in  the  program  is  a constant.  Thus, 
if  we  can  estimate  the  initial  number  of  errors  in  the  system  at  the  start  of 
debugging  and  keep  careful  records  of  those  removed  we  have  a good  esti- 
mate of  the  number  of  remaining  errors.  In  1973  Shooman  described  a test 
procedure  for  estimating  the  initial  number  of  errors. 

In  this  work  we  add  a major  refinement  to  the  above  models  by  intro- 
ducing the  possibility  of  error  generation  during  debugging.  A generated 
error  is  due  to  one  of  two  causes;  (1)  a bug  whose  correction  is  invalid 
and  further  debugging  on  the  same  statements  is  essential,  (2)  a new  bug 
which  is  generated  as  the  result  of  the  correction  of  a different  error.  The 
error  generation  terms  are  modeled  in  several  different  ways:  proportional 

to  the  number  of  detected  errors,  corrected  errors,  the  number  of  remain- 
ing errors,  or  some  function  of  these  effects.  The  correction  rate  is  as- 
sumed to  be  a function  of  the  manpower  deployed  on  the  project,  thus,  one 
can  use  the  model  to  investigate  optimum  manpower  deployment  strategies. 
The  effects  on  the  economics  of  debugging  due  to  error  growth  have  also 
been  analyzed. 
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INTRODUCTION 

The  concept  of  reliability  as  applied  to  the  performance  of  computer 
programs  is  in  its  infancy.  Software  packages  with  an  ever  increasing 
degree  of  complexity  have  emerged  in  the  last  decade.  It  is  therefore  im- 
perative to  have  highly  reliable  software  systems  when  large  software 
packages  are  required  to  perform  complex,  real-time  operations  as,  for 
example,  in  the  case  of  a moonlanding  mission. 

The  theory  of  Software  Reliability  differs  from  that  of  Hardware  Relia- 
bility in  that  system  failure  is  not  due  to  part  failures  (which  are  due  to  a 
variety  of  causes)  but  is  caused  by  software  bugs  which  are  really  latent 
design  errors.  Once  a software  defect  is  properly  fixed  it  is  in  general 
fixed  for  all  time.  Failure  usually  occurs  only  when  a program  is  exposed 
to  an  environment  that  it  was  not  designed  or  tested  for.  The  large  num- 
ber of  possible  states  of  a program  and  its  inputs  make  perfect  compre- 
hension of  the  program  requirements  and  implementation  and  complete  test- 
ing of  the  program  generally  impossible.  Thus  Software  Reliability  is  es- 
sentially a measure  of  the  confidence  we  have  in  the  design  and  it's  ability 
to  function  properly  in  all  environments  it  is  expected  to  be  subjected  to. 

In  the  life  cycle  of  software  there  are  generally  one  or  more  test  phases 
during  which  reliability  improves  as  errors  are  identified  and  corrected. 

The  first  few  months  of  operation  may  include  either:  (1)  a non-growth  opera- 

tional phase  during  which  further  corrections  are  not  made  (for  practical 
and  economic  reasons)  and  reliability  is  constant,  or  (2)  further  debugging 
and  correction  of  errors  as  they  occur  which  essentially  amounts  to  the  use 
of  early  operation  as  a final  debugging  test. 

Reliability  predictions  are  made  based  on  the  estimation  of  the  number 
of  errors  present  in  a program.  In  Chapter  2 is  discussed  some  of  the 
pioneering  work  r 1 — 3 ] done  in  this  field.  The  approach  used  there  was  to 
study  the  debugging  history  of  previous  programs  similar  to  the  one  in 
question.  From  these  one  determined  constants  for  the  model  and  made 
predictions  in  the  initial  planning  stages  of  the  system  reliability  and  the 
required  debugging.  Any  change  to  increase  the  accuracy  of  the  estimate 
was  made  after  error  data  was  available  for  the  current  project.  The  er- 
ror models  were  developed  with  the  assumption  that  no  new  errors  are 
added  to  a program  during  it's  debugging  phase.  In  other  words  the  cumu- 
lative error  correction  curve  approaches  a horizontal  asymptote.  This 
however  is  contrary  to  practical  experience. 

Discussions  with  program  managers  have  revealed  that  a certain 
amount  of  bug  generation  is  associated  with  every  debugging  process. 

Some  of  the  ways  in  which  errors  may  be  generated  are 

1.  The  correction  of  a bug  may  work  locally  only  (i.  e. , the 
global  aspects  of  the  error  still  remain). 

2.  A typographical  error  may  arise  invalidating  the  result 
of  bug  correction. 
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3.  The  correction  is  based  upon  faulty  analysis,  thus  com- 
plete bug  removal  is  not  accomplished. 

4.  The  correction  is  accomplished,  however,  it  is  accom- 
panied by  the  creation  of  a new  error, 

5.  Errors  which  are  detected  but  not  corrected,  act  in 
many  ways  like  generated  errors. 

During  the  development  phase  we  are  faced  with  two  classes  of  changes 
in  a program,  those  due  to  changes  in  the  specifications  (design)  and  those 
necessary  to  correct  software  errors.  Although  both  classes  of  changes 
are  important  we  only  discuss  the  changes  needed  for  error  correction.  In 
evaluating  the  constants  of  the  models  from  data,  it  is  important  to  keep 
careful  records  so  one  is  able  to  differentiate  between  these  two  effects. 

The  concept  of  bug  generation  is  analyzed  in  the  following  chapters. 

In  Chapter  5,  a two-phase  model  for  the  error  correction  rate  leads  to 
various  possibilities  for  a hypothetical  model.  An  economic  analysis  of 
debugging  follows  in  Chapter  6. 


2.  1 Introduction 


CHAPTER  2 

SUMMARY  OF  EXISTING  MODELS 


Earlier  error  models  developed  in  the  literature  assume  that  the  total 
number  of  errors  in  a program  is  fixed  and  that  if  we  record  the  cumulative 
number  of  errors  corrected  during  debugging,  then  the  difference  between 
the  initial  number  and  the  number  corrected  represents  the  remaining  er- 
rors. The  reliability  models  to  be  discussed  in  this  chapter  relate  the  prob- 
ability of  encountering  a software  bug  to  the  number  of  residual  bugs,  the 
total  number  of  instructions  and  the  instruction  processing  rate, 

2.  2 Error  Decay  Model 

Assuming  that  a careful  record  of  errors  corrected  is  maintained,  a 
graph  of  error  correction  rate  versus  debugging  time  may  be  drawn.  The 
debugging  process  starts  with  the  number  of  errors  corrected  being  equal 
to  zero,  and  the  time  axis  starts  at  the  instant  the  debuggers  begin  work. 

The  debugging  rate  is  defined  as 


rc(r)=  errors  removed/debugging  time  T 


(2.  1) 


Using  Eq.  (2.1)  a cumulative  error  curve  , n^x),  can  be  defined  as 

T 

nc(T)=  fr^dx  (2.2) 

0 


Solving  Eq.  (2.  2)  for  r^r),  the  slope  of  the  nc(T)  curve,  we  obtain 


r 

c 


(t)  = 


dnc(T) 

dr 


(2.3) 


If  we  assume  that  the  total  number  of  errors  in  the  program,  n^  re- 
mains constant,  then  the  curve  nc(T)  approaches  n asymptotically  Tor 
large  r.  Assuming  that  all  detected  errors  are  corrected  we  can  write 
for  the  remaining  errors  n(x) 


n(r)  = nt  - nc(T) 


(2.  4) 


If  we  further  assume  that  in  any  sizable  program  it  is  impossible  to  remove 
all  errors,  then 


nc(T)  < nt 

and 

n(r)  > 0 


(2.  5) 
(2.  6) 
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2.  3 Reliability  Model 

In  order  to  formulate  a reliability  model,  we  assume  that  operational 
software  errors  occur  due  to  the  occasional  traversing  of  a portion  of  the 
program  in  which  a hidden  software  bug  is  present.  An  expression  for  the 
probability  that  a bug  is  encountered  in  the  time  interval  At  after  t hours 
of  successful  operation  may  be  derived.  This  must  be  proportional  to  the 
probability  that  any  randomly  chosen  instruction  contains  a bug.  If  we  fur- 
ther assume  that  all  instructions  are  equally  likely,  and  that  all  bugs  are 
homogeneously  and  randomly  distributed,  then  the  probability  that  a ran- 
domly chosen  instruction  contains  a bug  is  given  by  the  number  of  errors 
normalized  with  respect  to  the  total  number  of  instructions  ec(r)  = n^Jrj/lrj. 
where  1,^.  = total  number  of  instructions. 

From  reliability  and  probability  theory  [ll]  it  is  obvious  that  the  prob- 
ability of  failure  in  the  interval  t to  t + At,  given  that  no  failures  have  oc- 
curred till  time  t is  proportional  to  the  failure  rate  (hazard  function)  Z(t). 
Mathematically  we  may  write  the  above  argument  as 


P[t  < tf  < (t  + At)/tf  > t]  = Z(t)  At  = kj  er(r)  rpAt  (2.  7) 

where 

tj  = operating  time  to  failure  (occurrence  of  a software  error) 

kj  = an  arbitrary  constant 


e (t)  = number  of  remaining  errors  normalized  with  respect  to 

the  number  of  instructions,  i.  e. , n(r)/lrp 

rp  = the  rate  of  instruction  processing 

In  thej  past  there  have  been  difficulties  in  defining  rx  since  for  each 
loop,  the  rate  at  which  the  instructions  are  processed  varies.  Also  if  in- 
terruptions or  jumps  or  calls  to  subroutines  occur  the  processing  rate 
varies.  To  overcome  this  problem  a simplified  model  is  used, 

z(t)  At  = k ef(r)  At  (2.  7a) 


where  k = an  arbitrary  constant  which  must  be  measured  for  the  particular 
program  = k.  r . 

A Jr 

From  reliability  theory  [ll]  it  can  be  shown  that  the  probability  of  no 
system  failures  in  the  interval  (o,  t)  is  the  reliability  function  which  is  re- 
lated to  the  hazard  function  by 


R(t)  = exp 


t 

f z(x)  dx 

0 


(2.  8) 
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Substituting  for  z(t)  from  Eq,  (2.7a)  into  Eq.  (2.  8)  and  assuming  k and 
e r(r)  are  independent  of  operating  time  t we  obtain 


R(t)  = exp{-k  er(r)t)  = exp(yt) 


(2.9) 


Equation  (2.  9)  states  that  the  probability  of  successful  operation  without 
bugs  is  an  exponential  function  of  operating  time. 

Using  the  reliability  model  the  MTTF,  mean  time  to  (software)  failure 
can  be  easily  computed  [ll 


00 


MTTF  = f R(t)  dt 
0 


(2.10) 


Explaining  the  above  set  of  equations  we  find  that  to  measure  the  parame- 
ters in  the  model  we  have  to  work  backwards.  By  operating  the  program 
in  a real  or  simulated  manner  MTTF  [l]  can  be  observed.  Substitution 
from  Eq.  (2.  9)  into  Eq.  (2.  10)  yields 


00 


MTTF  = f exp(-yt)  dt  = l/y  (2.11) 

0 

By  substituting  Eqs.  (2.  2,  2.  4 and  2.  9)  into  Eq.  (2.  11 ) we  obtain 


MTTF  = l/k 


xrr* 


rc(x)  dx 


(2.  12) 


Assuming  that  careful  error  records  are  kept, 

f rc(x)  dx 
0 

is  known.  The  two  remaining  parameters  to  be  determined,  k and  nt, 
are  determined  by  measuring  the  MTTF  at  two  different  values  of  t»  If 
we  further  assume  that  rc(7)  is  a constant  equal  to  r , then  Eq.  (2.  12) 
reduces  to 


n. 


MTTF  = l/k(  t 


(2.  13) 


As  we  said  earlier,  if  we  work  backwards  with  a record  of  MTTF  and  with 
a knowledge  of  tq,  t,  1^.  and  k,  nt  can  be  computed  using  Eq.  (2.  13). 
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2.  4 Summary 


In  the  foregoing  discussion  it  has  been  assumed  that  the  total  errors 
which  is  a sum  of  those  errors  remaining  in  the  program  and  those  elimi- 
nated remains  constant  during  the  debugging  process.  This  assumption  has 
been  made  in  order  to  predict  a behavior  with  less  mathematical  complexity. 
In  reality  there  is  a generation  of  errors  associated  with  correction.  As  a 
result  of  this  the  total  number  of  errors  increases  with  time.  Such  a beha- 
vior of  bugs  will  be  investigated  in  the  following  chapters. 
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CHAPTER  3 


SURVEY  OF  DEBUGGING  DATA 


3.  1 Introduction 

To  derive  accurate  values  for  model  parameters  and  to  verify  the  valid- 
ity of  the  models  a wide  range  of  data  is  necessary.  However,  one  can  es- 
tablish the  model  with  limited  data  and  refine  the  parameters  (and  perhaps 
the  form)  of  the  model  with  data  which  will  be  available  at  a later  date.  The 
data  discussed  in  this  chapter  can  be  used  to  determine  the  parameters  of 
the  models  in  Chapter  2 as  well  as  those  in  the  following  chapters, 

3.  2 Large  program  data 

Seven  different  programs  were  studied  in  the  literature  [ l]  and  the  er- 
ror content  (number  of  errors  removed)  was  recorded.  These  are  shown  in 
Table  3.  1.  Figures  3.  1 and  3.  2 show  the  normalized  changes  recorded 
every  month.  From  those  figures  we  observe  a generally  decreasing  trend 
in  error  rate  versus  debugging  time.  One  possible  explanation  of  this  phe- 
nomenon is,  if  debugging  is  efficient  then  the  errors  decrease  with  time.  If 
fewer  errors  are  present  then  the  number  of  errors  discovered  and  removed 
are  also  few.  This  above  argument  is  at  present  unsubstantiated  and  may 
be  thought  of  as  a hypothesis. 

3.  3 Errors  removed  proportional  to  errors  remaining 

One  of  the  error  models  proposed  by  Shooman  [ 1 ] is  that  the  number  of 
errors  removed  is  proportional  to  the  number  of  remaining  errors.  Mathe- 
matically we  may  write* 

rc(T)=  kc(nt  ■ nc}  ai) 

where 


r (t)  = error  correction  rate 
c 

nt  = total  errors,  i.  e.  , sum  of  those  removed  and  those  remaining 

n = number  of  errors  removed 
c 

kc  = a constant  of  proportionality 
dn 


since 


r (t)  = -j — 

c ' dT 


(3.2) 


* 


The  notation  in  this  report  differs  slightly  from  that  used  in  the  literature. 
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If  we  assume  no  new  errors  are  generated  and  that  all  errors  detected  are 
immediately  and  perfectly  corrected,  then 


dn 

= k (n  - n ) 
dr  c t c ' 


or 


dn 


+ k n = k n 


dr  ' "c"c  "c”t 
A solution  of  Eq.  (3.  4)  yields 


n (t)  = nt  + A exp(-kcr) 


(3.  3) 


(3.4) 


(3.5) 


Using  the  initial  condition  that  nc(r=0)  = 0 at  t = 0 we  get  A = -nt. 

Thus  the  cumulative  error  correction  curve  becomes  the  exponential 
rise  to  the  asymptote  n^ 

nc<T)=  nt(l  - exp(-kcT)}  (3.6) 

Figures  3.  3 and  3.  4 are  plots  of  cumulative  errors  corrected  from  the  data 
in  Table  3.  1.  These  curves  have  a profile  similar  to  an  exponential  only 
during  the  later  part  of  debugging.  Therefore,  Eq.  (3.  6)  cannot  entirely 
describe  these  curves.  To  understand  the  dynamics  of  error  behavior,  the 
data  from  Figs.  3.  1 and  3.2  is  redrawn  as  continuous  curves  in  Figs. 

3.  5(a-f).  The  scales  are  suitably  normalized.  Let  us  postulate  a model  in 
which  error  correction  rate  per  man-month  decays  exponentially  (Fig.  3.  6a) 
during  the  course  of  debugging.  If  we  further  assume  a triangular  distribu- 
tion of  manpower  as  illustrated  in  Fig.  3.  6b,  then  a product  of  the  ordinates 
of  the  curves  in  Figs.  3.  6(a  and  b)  gives  rise  to  the  number  of  errors  cor- 
rected per  month.  The  resulting  curve  Fig.  3.6c  rate  appears  to  be  some- 
what similar  to  those  in  Figs.  3.  5(a-f),  and  an  integral  of  this  curve  (Fig. 

3.  6d)  over  the  debugging  period  gives  the  cumulative  errors  corrected.  We 
are,  however,  unable  to  compare  quantitatively  the  hypothetical  curve  with 
those  obtained  using  the  data,  because  a comparison  depends  upon  the  scales 
used  and  the  scale  for  the  hypothetical  curve  is  not  based  on  data.  In  con- 
clusion we  may  say  that  the  error  model  as  shown  in  Fig.  3.  6 resembles 
the  profile  of  some  of  the  experimental  curves  shown  in  Fig.  3.  5. 

3.4  Debugging  effort 

Before  we  can  postulate  an  error  model  it  is  advisable  to  refer  to  other 
developments  that  have  taken  place  in  this  field.  An  experiment  on  debug- 
ging of  a 4000  machine  language  program  was  conducted  at  Bell  Laborator- 
ies [6],  In  conducting  this  experiment  programmers  were  asked  to  fill  a cer- 
tain Trouble  Report/Correction  Report  (TR/CR)  form  and  another  supplemen- 
tary form  in  order  to  derive  relevant  information  regarding  the  nature  of  bugs. 
Sixty-three  such  forms  were  completed.  Out  of  the  63  TRs  generated,  il 
contained  no  errors  and  7 contained  minor  annoyances  which  would  in  all 
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probability  not  be  defined  as  a bug.  Thus  there  were  45  real  errors.  This 
works  out  to  be  approximately  1%  of  the  total  lines  of  code  which  the  pro- 
grammers declared  to  be  in  agreement  with  previous  data.  One  of  the  out- 
comes of  this  experiment  is  a record  of  the  time  taken  to  remove  each  error. 
Figure  3.  7 shows  the  working  time  and  computer  time  expended  in  the  de- 
bugging  process.  A careful  examination  of  this  figure  reveals  that  except 
for  a few  spikes,  the  time  expended  while  working  on  most  of  the  errors  is 
approximately  the  same.  This  leads  us  to  conclude  that  the  rate  of  error 
correction  is  a constant.  We  will  use  this  assumption  in  Chapter  4 and  grove 
that  it  leads  to  anomalous  results. 

F.  Akiyama  [ 8J  reports  another  study  on  software  debugging.  At  Fujitsu 
Limited  in  Tokyo  a system  called  SAMPLE  (running  under  the  Monitor  V of 
FACOM  230-60  the  Fujitsu  large-scale  computer)was  developed.  The 
SAMPLE  consists  of  seven  modules  and  was  programmed  in  FASP,  the 
assembler  language  for  FACOM  230-60.  The  program  sizes  and  the  organi- 
zation of  SAMPLE  are  shown  in  Table  3.  2.  Table  3.  3 shows  the  relation- 
ship between  the  nature  of  the  program  and  the  occurrence  of  bugs  for  each 
module,  while  Fig.  3.8  portrays  the  cumulative  number  of  bugs  as  a function 
of  the  development  time.  A careful  examination  of  Fig.  3.  5 shows  that  the 
error  correction  rate  was  not  a constant  all  through  the  process  of  debugg- 
ing. It  decreased  toward  the  later  part  of  debugging.  All  these  curves  have 
a horizontal  asymptote  which  shows  that  the  number  of  errors  corrected 
reaches  a saturation  level.  Calculation  of  the  cumulative  error  curves  from 
the  data  in  Ref.  [ l]  displays  a similar  behavior.  (Also  illustrated  in  Fig. 3.4) 
We  will  concentrate  on  this  idea  and  use  it  in  the  following  chapters. 


Having  reviewed  some  of  the  available  literature  in  this  area,  we  should 
now  be  able  to  proceed  further  with  our  error  model. 
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TABLE  3.  2 

SAMPLE'S  structure  and  scale  of  each  module 


Module 

Program  steps 

name 

(Kilo  step) 

Note 

MA 

4.  03 

experimental 

module 

MB 

1.32 

MC 

5.45 

MD 

1.67 

ME 

2.  05 

MF 

2.  51 

MT 

2.  10 

Common  program 
table  and  message 
string 

Total 

19.  13 

(see  Reference  8) 


Pix)*  changes  /instruction  xIO 


Fig.  3.  2 Normalized  error  rate  versus  debugging  time  for  fou 
applications  programs.  (See  Reference  1) 


Fig.  3.  3 Cumulative  error  curve  for  supervisory  system  A given  in 
Figure  1.  (See  Reference  1) 


Cumulative  Errors  Removed  / Instruction  xIO 


01  2345678 

Number  of  months  of  Debugging 

Fig.  3.  4 Cumulative  error  curves  for  some  of  the  systems  in 
Figures  3.  1 and  3.2  (See  Reference  1) 


No.  of  Errors 

Cumulative  Errors  Corrected  Corrected /month 


Fig,  5.  5a  Error  rate  curve  and  cumulative  error  curve  for 
supervisory  A of  Fig.  3.  1 (Suitably  normalized) 

(i)  Envelope  of  the  error  rate  curve  for  Supervisory  A 

(ii)  Cumulative  error  curve  for  Supervisory  A (see 
Reference  1 ) 


Cumulative  Errors  Corrected  No.  of  Errors  Corrected  /mo 


Number  of  Months  of  Debugging 


Fig.  3.  5b  Error  rate  curve  and  cumulative  error  curve  for 
supervisory  B of  Fig.  3.  1 (suitably  normalized) 

(i)  Envelope  of  the  error  rate  curve  for  Supervisory  B 

(ii)  Cumulative  error  curve  for  Supervisory  B (see 
Reference  1 ) 


Number  of  Months  of  Debugging 


Fig.  3.  5c  Error  rate  curve  and  cumulative  error  curve  for 
Supervisory  C of  Fig.  3.  1 (suitab’y  normalized) 

(i)  Envelope  of  the  error  rate  curve  for  Supervisory  C 

(ii)  Cumulative  error  curve  for  Supervisory  C (see 
Refe  rence  1 ) 
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Cumulative  Errors  Corrected  No.  of  Errors  Corrected/fnonth 


Number  of  Months  of  Debugging 

Fig.  3.  5d  Error  rate  curve  and  cumulative  error  curve  for 
Application  A of  Fig.  3.  2 (suitably  normalized) 

(i)  Envelope  of  the  error  rate  curve  for  Application  A 

(ii)  Cumulative  error  curve  for  Application  A (see 
Reference  1 ) 
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Cumulative  Errors  Corrected  No.  of  Errors  Corrected/month 


Number  of  Months  of  Debugging 


Fig.  3.  5e  Error  rate  curve  and  cumulative  error  curve  for 
Application  B of  Fig.  3.  2 (suitably  normalized) 

(i)  Envelope  of  error  rate  curve  for  Application  B 

(ii)  Cumulative  error  curve  for  Application  B (see 
Reference  1 ) 
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Cumulative  Errors  Corrected  No.  of  Errors  Corrected/mo. 


Number  of  Months  of  Debugging 


Fig.  3.  5f  Error  rate  curve  and  cumulative  error  curve  for 
Application  C of  Fig.  3.  2 (suitably  normalized) 

(i)  Envelope  of  the  error  rate  curve  for  Application  C 

(ii)  Cumulative  error  curve  for  Application  C (see 
Fe  fe  rence  1 ) 
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Cumulative  Errors  Errors  Number  of  men  Errors 

Removed  Removed  /tnonth  Employed  Removed/month 


2 4 


6 8 


4 6 


Number  of  Months  of  Debugging 


Fig.  3.  Hypothetical  error  model  based  on  the  profile  of  curves  in 
Figs.  3.  3 and  3.  5 

(a)  Variation  of  error  removal  per  man-month  over  the 
debugging  time 

(b)  Variation  of  manpower  over  the  debugging  time 

(c)  Variation  of  error  removal  per  month  over  the 
debugging  time 

(d)  Cumulative  error  removal 


Working  Time  to.  Diognose 
and  Correct,  Compared 


Fig.  3.7a  Working  Time  expended  in  Debugging  as  observed  at  Bell 
Labs.  (See  Reference  6) 
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Computer  lime  to  Diognose 
and  Correct,  Compared. 


Computer  Time  to 
Diagnose  (Minutes)  30 
20 
10 

TR/CR  Number  q 
10 

Computer  Time  to  20 
Correct  (Minutes) 

2 hours  1 


No  Errors  19,24,26,33,42,47,50,56, 
58.60,63. 

Note:-  See  Note'  for*  Figure  6 


Fig.  3.7b  Computer  Time  expended  in  Debugging  as  observed  at 
Bell  Labs.  (See  Reference  6) 
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CHAPTER  4 


ERROR  GENERATION  MODEL 


4.  1 Introduction 

In  Chapter  2 we  discussed  an  error  model  in  which  the  total  number  of 
program  errors  remained  constant.  At  this  point  we  examine  the  assump- 
tion that  it  is  feasible  to  debug  without  generating  an  error.  Most  software 
personnel  agree  that  there  is  a certain  generation  of  errors  associated  with 
correction.  The  ways  in  which  errors  are  generated  was  discussed  in  Chap- 
ter 1. 


Depending  upon  the  efficiency  of  debugging,  the  error  generation  rate 
could  be  greater  than,  equal  to  or  less  than  the  error  correction  rate.  The 
resulting  error  behavior  in  the  three  cases  is  shown  qualitatively  in  Fig. 
4,1.  (Figure  4.  la  is  a particular  case  where  there  is  no  generation  of  er- 
rors) [3],  The  time  t.  is  when  debugging  stops.  Note  that  the  number  of 
errors  remaining  ">  0,  *in  each  case. 

4.  2 Model  for  Generated  Errors 

We  wish  to  develop  a set  of  equations  which  will  describe  the  above 
cases.  We  begin  by  writing  a difference  equation  for  the  number  of  errors 
in  the  program. 

Errors  present  at  time  t.  = [Errors  present  at  time  j ] 

+ [Errors  generated  in  the  interval  (t.-t.  ^)] 

- [Errors  removed  in  the  interval  (t-Tj  ^ )]. 

If  we  let 

n^(Tj,  t.  j)=  number  of  errors  generated  in  the  interval  (t.-t.  j) 

nd(Ti*  Ti  1 )=  number  of  errors  detected  in  the  interval  (t.-t^  j) 

nc(Tj,  r.  j)=  number  of  errors  corrected  in  the  interval  (t^-t.  j) 

then  the  number  of  errors  remaining  in  the  program  at  time  t.,  n(<r. ),  is 

given  by  the  following  difference  equation  1 

n(r.)  = n(Tul)  + n^,  t.j)  - nc(T.,  t.^)  (4.  1) 

Conversion  of  the  above  difference  equation  to  a differential  equation  is  per- 
formed by  grouping  terms,  dividing  both  sides  by  .)  3 At  and  taking 

limits  11-1 
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lim 
At  — ■ 


n^)  - n(T._j) 
Sr 


ng  ^Ti*  Ti  - 1 ^ 
At 


lim 
At  — ' 0 


n (t.,  t.  . ) 

C l*  l- 1 ' 

At  | 
(4.2) 


The  left-hand  side  of  Eq.  (4.  2)  is  recognized  as  the  rate  of  change  of  er- 
rors remaining,  i.  e. , the  derivative  of  n with  respect  to  t.  The  right- 
hand  side  is  composed  of  two  terms,  which  as  the  limit  is  approached 
become  the  rates  of  error  generation  and  correction  respectively.  The  no 
tation  for  error  rates  is  given  below 


rg(Ti> 

rc(Ti> 

rd(Ti> 


= Generation  rate  of  new  errors  at  time  t. 
= Correction  rate  of  errors  at  time  t. 

— Detection  rate  of  errors  at  time  t. 


Using  the  above  definitions,  Eq.  (4.  2)  becomes 


r (t)  - r (t) 
dr  g'  ' c'  ' 


(4.3) 


In  Eq.  (4.  3)  the  term  accounting  for  error  generation  includes  all  the  five 
cases  discussed  in  Chapter  1 which  are  created  by  debugging  changes.  In 
a process  where  debugging  is  efficient^  the  generation  rate  is  smaller  than 
the  correction  rate  and  the  number  of  bugs  in  the  system  decreases.  A 
steady  state  is  reached  when  correction  decreases  so  that  dn(T)/  dT  = 0. 

(See  Fig.  4.  la  and  b)  Let  us  hypothetically  say  that  the  correction  rate  is 
proportional  to  the  detection  rate. 

rc(T)  = |3  rd(T)  (4.4) 

In  the  ideal  case,  all  detected  errors  are  immediately  corrected  and 
(3=1.  However,  in  practice  0<  (3  < 1 because  some  detected  errors  may 
be  incorrectly  fixed.  The  latter  effect  adds  to  the  generation  as  previously 
discussed. 

The  generation  effect  is  more  complicated  to  model.  If  we  assume  tha 
the  generation  rate  is  proportional  to  correction  rate,  then 

r (t)  = a r (t)  (4.  5) 

6 C 

Combining  Eqs.  (4.  3),  (4.  4)  and  (4.  5)  yields 

= <*rc(T)  - 0rd(T)=  0(0-1)  rd(T)  (4.6) 

Inspection  of  Eq.  (4.6)  shows  that  the  effect  under  these  assumptions 
for  the  normal  case  where  a < 1 is  that  the  number  of  errors  decreases. 
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However,  if  a>  1,  generation  exceeds  correction  and  the  result  illustrated 
in  Fig.  4.  lc  is  obtained.  If  a = 0,  there  is  no  generation,  but  in  general 
0 < a < 1 and  the  effect  of  error  generation  is  to  reduce  the  effective  cor- 
rection rate  (see  case  1,  Appendix  I).  From  the  solution  we  can  see  that 
for  large  t,  n(T)  becomes  negative  which  leads  to  a physical  contradiction. 

We  may  explore  a different  model  by  assuming  the  detection  rate  is  in 
turn  proportional  to  the  number  of  remaining  errors.  This  leads  to  Case  3 
of  Appendix  I,  and  n(-r)  is  a decreasing  exponential.  This  result  agrees 
with  only  a part  of  the  experimental  data  reported  in  the  literature  [1,  8], 
since  shapes  other  than  decreasing  exponentials  have  also  been  observed 
for  n(r). 

A different  hypothesis  is  to  assume  that  generation  of  new  errors  is  a 
function  of  not  only  the  detection  rate,  but  also  the  number  of  remaining  er- 
rors. Clearly,  the  larger  the  number  of  detected  errors,  the  more  are  the 
changes  required  and  the  probability  of  creating  an  error  increases.  Also 
each  time  we  make  a change  there  is  a chance  that  this  will  interact  with 
existing  errors  and  create  new  errors  via  the  interaction.  Assuming  gene- 
ration is  a simple  product  of  these  two  functions  and  correction  is  as  given 
in  Eq.  (4.  4)  (with  |3  replaced  by  b)  we  obtain 


r (t)  = a n(r)  rd(r) 


(4.7) 


rc(T)=  b rd(r) 


(4.8) 


where  a and  b are  proportionality  constants.  Substituting  Eqs.  (4.7)  and 
(4.  8)  into  Eq.  (4.  3)  we  obtain 


= a n(r)  rd(T)  - b rd(r) 


(4.9) 


If  we  make  the  further  assumption  that  the  detection  rate  is  a constant,  r , 
Eq.  (4.  9)  becomes  ° 


= a r0  n(T)  - b rc 


(4.  10) 


The  above  differential  equation  can  be  readily  solved  by  taking  Laplace 
transforms  or  by  classical  differential  equation  theory  yielding 


n(r)  = (nQ  - b/a)  exp(a  rQr)  + b/a 


(4.  11) 


where  n(r  = 0)  = nQ. 


The  behavior  of  Eq.  (4.  11)  depends  upon  the  relative  values  of  n and 
b/a.  Since  the  probability  of  n being  exactly  equal  to  b/a  is  very  low, 
we  are  left  essentially  with  two  possibilities.  If  n > b/a,  then  n(r)  builds 
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up  exponentially.  If  nQ  < b/a,  the  number  of  errors  decreases  and  becomes 
negative  for  large  r.  The  two  cases  are  illustrated  in  Fig.  4.  2,  and  Case 
4,  Appendix  I. 

4.  3 Contradictions  and  Basis  for  a Reformulated  Model 

A negative  number  of  errors  has  no  physical  meaning,  thus  some  cases 
of  the  models  given  in  Table  A-l  lead  to  a contradiction.  Either  the  initial 
assumption  and  the  model  are  only  valid  for  a short  time  period  or  our  ini- 
tial assumptions  were  wrong.  In  fact  we  have  assumed  several  models  for 
error  generation  and  have  rejected  the  results  (Eqs.  4.  6 and  4.  1 1 ) because 
the  remaining  errors  went  negative  or  the  cumulative  error  correction 
curve  did  not  resemble  those  observed  experimentally.  We  now  turn  to- 
ward models  for  the  error  correction  rate  which  may  be  more  realistic, 
so  as  to  obtain  an  expression  for  n(T)  which  does  not  violate  physical  rea- 
soning and  fits  the  experimental  data. 

Programmers  have  reported  that  initially  the  bugs  are  easily  removed. 
Only  in  the  advanced  stage  of  debugging,  does  the  error  removal  become 
intricate.  Although  Shooman  and  Bolsky  [6]  present  evidence  that  the  effort 
to  fix  a bug  is  the  same  for  early  and  later  bugs,  they  did  not  feel  the  re- 
sult was  in  itself  conclusive  enough  to  overturn  the  intuitive  hypothesis  that 
the  later  bugs  are  the  hard  ones  to  fix.  In  Table  3.  1 and  Figs.  3.  1 and  3.  2 
we  observe  a decreasing  trend  in  the  correction  rate  with  debugging  time. 
Based  on  this  fact  if  we  assume  that  correction  rate  is  proportional  to  the 
number  of  remaining  errors,  then  this  leads  to  a cumulative  correction 
curve  which  does  not  conform  to  experimental  results.  A more  complex 
model  with  features  from  both  of  the  two  extreme  possibilities  is  developed 
in  the  next  chapter. 


NORMALIZED 

CUMULATIVE  ERRORS  DEBUGGED 


(•)  APPROACHING  EQUILIBRIUM,  HORIZONTAL  ASYMPTOTE,  NO  GENERATION  OF  NEW  ERRORS. 


(61  APPROACHING  EQUILIBRIUM , GENERATION  RATE  OP  NEW  ERRORS  EQUALS  ERROR 
REMOVAL  RATE. 


(* ) DIVERGING  PROCESS,  GENERATION  RATE  OF  NEW  ERRORS  EXCEEOS  ERROR 
REMOVAL  RATE. 


Fig.  4.  1 Cumulative  errors  debugged  versus  months  of  debugging. 
(See  Reference  3) 
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(b)  The  case  where  no  < b/a 


Fig.  4.  2 The  model  developed  under  the  assumptions  of  Case  4 
Table  A-l.  (See  Reference  4) 

32 


i 


; 


CHAPTER  5 

ERROR  CORRECTION  MODEL 


5.  1 Introduction 

In  Chapter  4 we  found  that  our  assumption  of  constant  error  correction 
rate  resulted  in  the  number  of  remaining  errors  eventually  going  negative. 
This  leaves  us  with  several  alternatives. 

1.  We  can  discount  the  results  of  the  experiment  conducted 
at  Bell  Labs  [6] 

2.  We  can  accept  the  earlier  hypothesis  that  the  correction 
rate  is  proportional  to  the  number  of  remaining  errors 

3.  We  could  formulate  other  hypotheses. 

There  is  no  definitive  answer  to  these  questions.  We  could  argue 
against  the  experiment  conducted  at  Bell  Labs  T6]  in  two  ways.  On  the  one 
hand  this  conclusion  was  based  on  the  results  of  just  one  experiment  con- 
ducted on  a program  which  can  be  considered  as  between  a small  and  me- 
dium sized  program.  Secondly,  the  reference  did  not  discuss  generation 
rate  of  errors.  In  Chapter  4 we  attempted  a few  models  for  error  genera- 
tion, Eqs.  (4.6)  and  (4.11),  and  found  the  results  unsatisfactory.  We 
now  turn  our  attention  toward  other  models  for  error  correction. 

5.  2 A Two-Phase  Model 


In  earlier  work  [l,  8],  a decreasing  trend  in  error  correction  rate  has 
been  observed  towards  the  later  part  of  debugging.  Figures  3.  3,  3.  4 and 
3.  8 illustrate  this  fact.  On  the  other  hand,  Shooman  and  Bolsky  [6]  ob- 
served a constant  correction  rate.  Also,  discussions  with  program  mana- 
gers have  led  to  the  conclusion  that  correction  rate  is  sometimes  manpower 
limited.  Thus,  we  postulate  a new  model  where  the  correction  rate  remains 
constant  during  the  early  stage  of  debugging  (manpower  limited).  We  as- 
sume that  later  in  the  program  another  stage  is  reached  where  the  correc- 
tion rate  is  proportional  to  the  number  of  remaining  errors.  During  both 
these  correction  stages  we  assume  the  error  generation  rate  is  proportion- 
al to  the  product  of  the  number  of  remaining  errors  and  the  number  of  de- 
tected errors  as  in  Eq.  (4.  7).  The  transition  from  the  early  stage  model 
of  error  correction  to  the  later  stage  model  may  be  considered  to  occur  at 


a critical  value  of  the 
assumptions  lead  to 

remaining  number  of  bugs  which  we  call  n^. 

These 

rg  = Pj  n(r)  rd(T) 

for  all  n(-r) 

(5.  i) 

rc  * P2  rd(T> 

for  all  n(«r)  > n^  [Region  1] 

(5.  2a) 

= p3  n(r)  rd(T) 

for  n(r)  < n^  f Region  2] 

(5.  2b) 

where  p^,  P3  are  constants  of  proportionality. 

I 


a 
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If  we  make  the  further  assumption  that  r^(r)  is  a constant  we  obtain 


y aj  n<T> 

rc  = kj  for  n(T)  > n^ 

= k^  h(r)  for  n(T)  < n^ 

where 

al  = Pi  rd(T) 

kl  = p2  rd(T) 
k2=  P3  rd(T) 


(5.3) 

(5.  4a) 
(5.  4b) 


5.  3 A Manpower  Limited  Model 

The  model  which  was  developed  in  the  previous  section  retains  the  as- 
sumption made  in  Chapter  4 that  the  error  generation  rate  is  proportional 
to  the  number  of  errors  remaining  [c.  f. , Eq.  (5.  3)].  However,  the  correc- 
tion rate  is  governed  by  Eqs.  (5.  4a  and  b).  Rewriting  Eq.  (4.3)  for  con- 
venience we  have 


= r (t)  - r (t) 
dT  g'  ' c' 


(5.  5) 


Substituting  Eqs.  (5.  3)  and  (5.  4a)  into  Eq.  (5.  5)  we  get  for  the  early 
phase  where  n(-r)  > n^  (called  Region  1) 


* a,  „<t)  - k) 


(5.6) 


The  solution  of  Eq.  (5.  6)  is  accomplished  in  a manner  similar  to  Eq. 
(4.  11)  yielding 


2i  T 

n(T)  = (nQ  - kj/aj)  e 1 + kj/aj 


(5.7) 


where 


n(T  = 0)  = nQ 

If  n > k,/aj  the  debugging  is  out  of  control  and  Eq.  (5.7)  indicates  that 
the  errors  build  up  exponentially  with  time.  * On  the  other  hand  if  nQ  < kj/aj, 

♦Discuss ion  with  experienced  software  managers  have  verified  that  on  rare 
occasions  debugging  does  go  out  of  control  and  either  the  program  is 
scrapped  and  rewritten  or  a new  team  of  'Super  Debuggers'  is  brought  in. 
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the  correction  process  is  efficient  and  the  errors  reduce  with  time.  Once 
the  errors  fall  to  the  critical  value  n^,  a transition  takes  place  in  the  error 
correction  rate  and  substitution  of  Eqs.  (5.  3)  and  (5.  4b)  into  Eq.  (5.5) 
yields 

= aj  n(  t ) -k2  n(T  ) (5.8) 


Letting  the  time  elapsed  in  reducing  the  number  of  errors  to  nj  be  a 
solution  of  Eq.  (5.  8)  yields 

n(r ) = nj  exp[(aj-k2)  (t-Tj)]  (5.9) 

The  conditions  under  which  the  transition  occurred  are  explained  as  follows: 
As  the  errors  decrease  the  number  of  men  employed  is  also  reduced  L 9 J • 
Since  we  intuitively  feel  that  the  later  bugs  are  harder  to  fix,  even  if  we 
maintain  the  ratio  of  the  number  of  errors  to  number  of  men  constant  we 
will  observe  a decreasing  correction  rate.  (Not^  this  contradicts  some  of 
the  results  of  Ref.  6.  ) We  have  assumed  an  abrupt  change  in  the  number  of 
men  employed  to  reduce  mathematical  complexity.  In  practice  the  change 
is  gradual. 

Eq.  (5.  9)  in  itself  gives  rise  to  two  cases  depending  upon  whether 

1 > k2 / ai  or  1<k2^al'  1/1  < k2^V  then  n*T)  decays  exponentially  to  zero 

as  t goes  to  infinity.  On  the  other  hand,  if  1 >k2/a1  then  n(-r)  increases 
exponentially,  thereby  re-entering  Region  1.  A physical  explanation  for 
why  the  switch  in  regions  may  occur  is  that  the  quantity  k^is  associated 
with  the  reduction  in  manpower.  As  testers  are  removedlrom  the  project, 
k decreases.  If  these  testers  are  removed  prematurely,  k,  may  decrease 
tc?the  extent  that  1 > k_/a,  thereby  causing  a re-entry  into  ICegion  1. 

With  increasing  errors  some  personnel  are  brought  back  and  a transition 
to  Region  2 will  soon  occur.  We  thus  can  have  an  oscillating  model.  It  is 
convenient  to  categorize  the  model  as 


Case  1 The  Unstable  Model 
Case  2 The  Controlled  Model 
Case  3 The  Oscillatory  Model 

The  three  cases  are  illustrated  qualitatively  in  Fig.  5.  1 and  summarized  in 
Case  5,  Appendix  I.  We  will  analyze  each  case  separately. 

Case  1 

In  Fig.  5.  la  the  errors  are  seen  to  diverge  exponentially.  If  the  software 
personnel  are  not  sufficiently  experienced,  a more  experienced  team  could 
be  brought  in  to  replace  the  current  one.  At  this  point  let  us  say,  the 
errors  have  built  up  to  n'  at  time  r'.  The  new  team  establishes  different  values 
for  kj  and  a}  (viz.  k'j  and  a'j  ) such  that  n*  < k^  / a'j  . 
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The  equation  describing  error  correction  is 


n (t)  = k.  t for  t < t' 
c'  ' i 


(5.  1 0) 


while  n(T)  is  described  by  Eq.  (5.  7).  The  total  number  of  errors  at  any 
time  is  the  sum  of  those  remaining  and  those  corrected,  resulting  in 


nt(r)  = n(T ) + nc(x) 


(5.  1 1 ) 


For  t > t'  the  error  equation  can  be  written  using  Eq.  (5.  7)  resulting  in 


n (t)  = (n*  - k j/a  j ) exp[a  j (t  - r'  )1  + k j/a  j 


The  error  correction  is  given  by 


nc<T)  = kjT  + k j (t-t*  ) 


(5.  12) 


(5.13) 


Equations  (5.  12)  and  (5.13)  are  applicable  between  r'  and  t.,  where  is 
the  instant  of  time  at  which  the  errors  fall  to  the  critical  value  n^.  Beyond 
t.  the  error  equation  is  defined  by  Eq.  (5.  9).  To  compute  the  number  of 
errors  corrected  we  can  rewrite  Eq.  (5.  4b)  as 

dn£  (t  ) 

— = .k^  n(T)  which  results  in 
n (t)  = f k n(r)  dT 


»c(t)  = rexp[(a'I  -kgHr-Tj)]  dT 


nc(r)  = 

^l‘k2 


exp[(a  1-k2)(T-TJ  )1  + C 


(5.14) 


I 

Using  the  boundary  condition  that  nc(T()  = k.T'  + ) which  is 

from  Eq.  (5.  13)  the  number  of  corrected  errors  in  Eq.  (5.  14)  may  b« 
written  down  as 

nc(T>=  V +k1(T1“T'  )+  >2  1 {expftaj-kjjJtr-Tj)]  -l) 

a rk2 


(5.  15) 
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Case  2 


The  initial  stage  here  is  described  by  Eq.  (5.7)  with  n < k./a..  The 
correction  is  governed  by  Eq.  (5.  10)  except  for  the  fact  tha*?  theequation 
holds  till  time  t..  The  errors  fall  exponentially  and  a transition  occurs 
at  t.  beyond  which  the  error  model  is  described  by  Eq.  (5.  9),  with 


* <Vv 


The  correction  curve  beyond  Tj  is  described  by  Eq.  (5.  14) 


with  only  a difference  of  ax  replacing  aj  and  the  boundary  condition 


being 


ne(Tl>'  Vt 


The  correction  curve  is  therefore  described  by 


k2"l 


nc<T>=kiT,  + a~Tt^  {exP[(a1-k2MT-Ti)]  -O  for  T1  Tt 


(5.  16) 


Case  3 


Tn  the  case  of  the  oscillatory  model  a substantial  number  of  errors  have 
been  removed  and  if  the  oscillations  can  be  broken  the  system  debugging  can 
be  promptly  completed.  As  explained  earlier  one  of  the  reasons  for  k2  be- 
ing less  than  a.  is  that  the  reassignment  of  some  of  the  debuggers  was  done 
prematurely.  If  the  transition  had  occurred  at  a lower  value  of  n,  the  pat- 
tern might  have  been  the  same  as  in  Case  2.  Therefore,  once  the  process 
goes  back  to  Region  1,  the  software  manager  may  increase  the  debugging 
personnel.  If  this  is  effective  we  may  stay  in  Region  2 till  completion  of 
debugging;  however,  if  personnel  are  removed  again  we  may  restart  the 
oscillatory  behavior. 


Here  the  initial  behavior  of  errors  is  given  by  Eq.  (5.  7)  with  nQ  < kj/a| 
while  the  correction  is  described  by  Eq.  (5.  10).  Upon  a transition  at  n = nj 
the  model  obeys  Eq.  (5.  9)  with  1 > After  transition  the  correction 


is  described  by  Eq,  (5.  16).  n(-r)  now  increases  to  at  time  T2  at  which 


point  another  transition  (this  happens  due  to  personnel  being  brought  back) 
occurs  bending  the  error  curve  downward.  Under  these  conditions  the  mo- 
del is  described  by  an  equation  similar  to  Eq.  (5.  7).  The  equation  is 


n(r)  = (n2  - kjAj ) expfa^r-  t2)]  + kj/aj 


(5.17) 


Using  Eq.  (5.  16)  the  correction  curve  can  now  be  written  as 


k2nl 


”c'T>'kri  + :7Tr  («*p{<vk2>(vT1,1  - o + 

1 u 


(5.18) 


for  t^.  t2 


The  errors  now  fall  until  a critical  point  defined  by  n=  n^*at  7j  when  another 


*n  is  set  smaller  than  n^  to  avoid  oscillations.  Under  these  conditions  Re 
gfon  2 includes  the  zone  where  n < n_.  The  software  team  now  establishes 
a new  value  for  k,  (viz.  k_)  such  that  1 < k,/a.. 
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transition  takes  place.  Below  n the  error  equation  is  described  by  an 
equation  similar  to  that  of  Eq.  (5.  9).  The  equation  is 


n(r)  = n3  exp[(a1-k3)(r-T3)]  for 


(5.  19) 


Once  again  Eq.  (5.  16)  can  be  used  to  write  an  equation  which  describes  the 
correction  beyond  Ty 


n (t)  = — 
c'  ' a 


k3n3 


{exp[(at -k3)(r- t3)]  - 1)  + nc(T3) 


(5.20) 


where 

nc(T3)=  klTl  + kl(T3'T2)  + {exp[(a1-k2)(T2-Ti)1  - 1} 

which  is  obtained  by  substituting  t,  for  t in  Eq.  (5.  18).  The  three  cases 

are  illustrated  in  Figs.  5.  2,  5.  3 and  5.  4.  An  initial  error  quantity  of 

n = 1 00  has  been  assumed  in  all  cases, 
o 

A PL/I  computer  program  (see  Appendix  II  for  a listing  and  flowchart) 
has  been  written  which  plots  the  number  of  remaining  errors,  the  cumula- 
tive corrected  errors  and  the  total  number  of  errors.  The  calculated  points 
for  the  curves  in  Figs.  5.  2,  5.  3 and  5.  4 were  computed  using  this  program. 

5.  4 Summary 

Many  of  the  features  of  these  models  agree  with  the  data  reported  in  the 
literature  and  the  experiences  of  program  managers.  Since  basic  data  on 
manpower  deployment,  error  rate,  the  rate  of  error  generation,  etc.,  are 
largely  unavailable,  testing  the  validity  of  the  above  models  must 
await  further  experimental  result.  Assuming  the  above  models  are  valid, 
we  can  investigate  the  economic  constraints  imposed  upon  Case  1.  An  eco- 
nomic break-even  between  rewriting  the  program  and  extensive  debugging 
is  discussed  in  the  next  chapter. 


(a)  Unstable  Model.  Errors  build-up 
indiscriminately. 


(b)  Controlled  Model.  Debugging  is  efficient. 


Fig.  5.  1 Remaining  errors  plotted  as  a function  of  months  of 
debugging. 
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Number  of  Errors 


Fig.  5.  2 Case  1 Unstable  Model  Controlled  Subsequently. 

(See  Eqs.  5.7,  5.  9,  5.  10,  5.  11,  5.  12,  5.  13.  5.  15) 


nti  mSII  ■ 
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Number  0/  Errors 


Debugging  effort  in  man— months 

Fig.  5.  3 Case  2 The  Controlled  Model. 

(See  Eqa.  5.7,  5.9,  5.  10,  5.  16) 


Number  of  Errors 


Debugging  effort  In  mon-months 


Fig.  5.4  Case  3 The  Oscillatory  Model  Oscillations  Controlled  after 
the  First  Bump.  (See  Eqs.  5.7,  5.  9,  5.  10,  5.  16,  5.  17, 

5.  18,  5.  19,  5.  20) 
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CHAPTER  6 


DEBUGGING  COST  MODELS 

6.  1 Introduction 

The  problem  of  computing  an  economic  break-even  point  looks  easy  at 
first  glance.  However,  it  involves  modeling  of  the  penalty  which  the  custo- 
mer will  demand  for  any  delay  caused  in  getting  the  system  working,*  Based 
on  the  models  previously  developed  there  is  no  closed  form  expression 
which  can  be  devised  to  calculate  compensation  because  there  is  no  closed 
form  expression  for  the  length  of  the  penalty  period.  This  is  clear  if  we 
examine  the  equation  describing  the  error  buildup  (c,  f.  Eq.  5.  7 with 
nQ  > kj/aj).  Since  this  equation  is  not  linear,  we  have  to  compute  the 
penalty  period  for  every  value  of  n(r).  However,  one  can  perform  a para- 
metric study  and  produce  tables  and/or  graphs  for  the  penalty  period. 


Programming  Economics  Without  Penalt\ 


In  Chapter  2,  we  stated  that -no  program  can  be  absolutely  free  of  er- 
rors, In  other  words,  bugs  cannot  be  eliminated  completely.  Therefore, 
the  economic  model  includes  the  effects  caused  by  a trace  of  residual  er- 
rors in  the  program.  Although  in  most  of  the  debugging  experiments  the 
errors  do  not  build  up  initially  (as  depicted  in  Case  1,  Chapter  5)  we  con- 
sider it  to  be  true  here  and  base  our  economic  model  on  this  extreme  case. 
However,  the  model  could  be  extended  to  cases  where  the  buildup  may  oc- 
cur sometime  during  the  course  of  debugging.  We  assume  that  the  errors 
build  up  from  n (initial  error  content)  to  n' . After  a transition  at  this 
point  (which  is  t?ie  result  of  introduction  of  super-debuggers),  the  errors 
fall  to  nj  where  the  next  transition  takes  place  (c.  f.  Eq.  5.  9).  The  errors 
subsequently  fall  to  a final  value  n^  which  is  the  residual  number  of  errors 
in  the  program.  The  final  value,  n which  is  achieved  must  result  in  a 
satisfactory  level  of  operational  reliability.  With  a knowledge  of  n1  , n.  and 
one  can  solve  Eqs.  (5.  9)  and  (5.  12)  and  calculate  the  time  required  to 
achieve  the  level  of  satisfaction  desired. 

We  are  not  interested  in  computing  the  expenses  prior  to  time  t'  (the 
instant  of  time  at  which  n(T)  has  built  up  to  n'  ) because  our  task  is  to  com- 
pare the  cost  of  rewriting  the  program  with  that  of  further  debugging.  The 
amount  of  money  expended  till  t*  has  no  influence  on  the  alternatives  that 
will  be  resorted  to.  Evaluation  of  the  time  expended  in  debugging  beyond 
T*  is  carried  out  by  solving  Eq.  (5.12)  for  t.  Since  t'  has  no  signifi- 
cance except  for  evaluating  the  penalty  which  is  explained  later,  we  may 
move  the  coordinate  axes  to  r'  . For  an  error  content  of  n we  get 


i . /"-kt/at 

T - — fn  — , 

a,  Vn'-k,/., 


(6.1) 


*A  contract  with  a penalty  clause  for  late  delivery  explicitly  states 
delay  penalty  in  dollars. 


The  time  r^f  for  the  errors  to  decrease  from  n'  to  n.  is  known  from 
Eq.  (6.  1)  by  fixing  n = n^.  Therefore 


t,  = — in 


■ . • 

ni  " k r a i 

— r i 

n - kf  /a 


(6.2) 


After  a transition  at  t = t the  error  mode’  is  described  by  Eq.  (5.  9). 
Solving  Eq.  (5.  9)  for  r we1  get 


t = t.  + — , 

(a,  -k2> 


(6.3) 


By  fixing  n = n2  (the  residual  number  of  bugs  in  the  program)  and  substitut- 
ing for  Tj  from  Eq.  (6.  2),  Eq.  (6.  3)  may  be  rewritten  as 


i . fni  - VaA . 
t2=  — in  -» 77-r  + 

ai  Vn  -ki/ai / 


1 . fn2) 

(a<  -k,)  Vni ) 


(6.4) 


where  T£  is  the  time  in  man-months  spent  in  reducing  the  number  of  errors 
from  rf  to  n^. 

For  simplicity  we  will  first  formulate  a model  which  does  not  involve 
any  penalty  for  delay.  Subsequently  we  will  include  penalty  terms  for  delay 
and  arrive  at  a thorough  analysis. 

Let  us  say  that  the  debugging  cost  per  man-month  is  c . Thus  the  de- 
bugging expense,  cd,  incurred  in  going  from  n'  to  n is 


Cj  = c T_ 
d o 2 


(6.  5) 


If  c represents  the  cost  of  rewriting,  debugging,  and  testing  the  program 
then  the  break-even  occurs  when  c,  * c.  Substituting  for  t?  from  Eq. 

(6.  4)  into  Eq.  (6.  5)  we  get  for  breax-even 


-i  - k'i/a'i 
-1 r— t 

n - k1/a1 


1 r ( 2 

a -k2  V* 


(6.  6) 


Solving  Eq.  (6.  6)  for  n*  we  get 
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n'  = exp 


ark2 


K3K 


1 - exp 


ark2 


- ill 


(6.7) 


Using  Eq.  (6.  7)  a curve  can  be  plotted  with  n'  as  a function  of  c/cq.  Since 
c is  the  total  cost  of  rewriting  and  c is  the  debugging  cost  per  man-month 
the  ratio  c/c  is  in  man-months.  Such  a curve  is  portrayed  in  Fig.  6.  1. 
This  curve  has  an  asymptote  n'  = k./a  . It  is  interesting  to  make  note  of 
the  outcome  if  n'  ■>  k^/a'  Undersuch  a condition  we  only  repeat  the  ear- 
lier situation  where  n > k^/a^.  The  values  assigned  to  kj  and  a^  by  the 
super-debuggers  are  unsatisfactory,  resulting  in  a further  buildup  of  errors. 


6.  3 Economics  with  Penalty 

To  understand  the  economics  involving  penalty  we  can  construct  a 
hypothetical  example.  We  shall  consider  a program  of  10,  000  machine 
language  words  having  an  initial  error  content  equal  to  1%  of  the  total 
lines  of  code  as  observed  by  Shooman  and  Bolsky  [6]  in  their  experi- 
ment. Let  us  begin  by  assuming  the  following  values  for  the  parame- 
ters in  the  foregoing  equations. 

n = 100  (1%  of  the  total  number  of  words),  k.  = 10,  a = 0.  125 
o 11 

ii  i . i 

k1  = 12.  5,  a^  = 0.  035,  k2  = 0.  15,  n^  = 20,  n2  = 1,  kj/a^  = 357 


kj/a^  = 80 


Reference  [10]  contains  an  analysis  of  the  development  costs  of  the  Apollo 
Spacecraft  guidance  and  control  computer  software.  Complete  statistics 
on  the  cost  of  software  development  were  discussed  in  the  report.  The  de- 
velopment cost  per  machine  word  ranges  from  $60  on  the  lower  limit  to 
$200  on  the  upper  limit  depending  upon  the  complexity  of  the  module.  The 
development  cost  includes  the  cost  of  writing,  debugging  and  testing.  De- 
bugging expense  was  rated  at  $3  000  per  man-month. 


We  make  a few  more  assumptions  which  are  listed  below. 


♦Number  of  men  employed  in  Region  1 
(i.  e. , n •>  n^ ) * 8 

♦Number  of  men  employed  in  Region  2 


(i.  e. , n < n1 ) 

Contract  period 
Writing  period 
Debugging  and  Testing 
Grace  Period 
Debugging  expense 
Development  cost 
Profit 

Penalty  per  month  of  delay 


= 4 

= 18  Months 

= 9 Months 

= 7.  5 Months 

= 1.5  Months 

= $3  000/ Man-Month 
= $ 50/ Word 

= 20%  of  development  cost 

= 1%  of  contract  price 


The  development  cost  works  out  to  be  $500,  000.  With  20%  profit  the  con- 
tract price  is  $600,  000.  Penalty  is  fixed  at  $6000  for  every  month  of  delay. 


In  order  to  evaluate  penalty  it  is  essential  to  know  the  amount  of  time 
expended  from  the  commencement  of  debugging.  Using  Eq.  (5.  7)  we  can 
write  the  effort  (man-months)  wasted  in  building  the  errors  up  to  n'  as 


(6.  8) 


Since  the  number  of  men  employed  are  8 and  4 in  Regions  1 and  2,  respec- 
tively, the  amount  of  time  (months)  spent  from  the  start  of  debugging  is 


T +T 


T = 


1 , T2~T1 


(6.9) 


Let  us  consider  an  extreme  case  where  n'  = 350. 


Using  Eq.  (6-8)  we 

get 

T*  = 

20.  82  man-months 

From  Eq.  (6.  2)  we 

find 

Tt  = 

1 1 0.  70  man-months 

and  from  Eq.  (6.  4) 

7 2 ~ 

1 3 6.  7 0 man-months 

Using  Eq.  (6.9) 

T = 

22.  94  months 

Since  we  have  assumed  a writing  time  of  9 months  the  total  period  = 
22.  94  + 9 = 31.  94  months. 


♦ For  further  details  on  Regions  see  Chapter  5.  ' 

**t2  *s  the  number  of  man-months  expended  in  reducing  the  errors  from  n' 
to  n^.  Hence  7^  is  a subset  of  7^  . 


Penalty  period  = Total  period  - Contract  period 


= 31.  94  - 1 8 = 13.94  months 

Extensive  debugging  cost  = $3 000/man-month  x 136.  70  man-months 

= $410,100  [using  Eq.  (6.5)] 

Penalty  in  Dollars  = $6000  x 13.  94  = $83,  640 

Further  debugging  therefore  costs  $41  0,  1 00  + $83,  640  = $493,  740. 

On  the  other  hand,  upon  finding  n'  = 350  if  the  decision  had  been  to  re- 
write then  the  total  time  spent  from  the  beginning  of  the  contract  would  be 
' first  writing  period  + t'  /8  + redevelopment  period. 

In  order  to  reduce  the  penalty  the  software  manager  expedites  the  pro- 
cess by  a month  and  a half  thus  resulting  in  a development  time  of  1 5 months. 
Therefore 

Total  period  = 9 + 2.  60*  + 15  = 26.  60  months 

Penalty  period  = 26.  60  - 18  = 8.  60  months 

Penalty  in  dollars  = 8.  60  x $6000  = $51,  600 

Redevelopment  cost  + penalty  = $500,  000  + $51,  600  = $551,  600 


6.4 


In  the  foregoing  example  it  is  seen  that  extensive  debugging  works  out 
to  be  more  economical  compared  to  rewriting  although  the  errors  have 
built  up  indiscriminately.  In  practice  such  a buildup  is  unthinkable.  How- 
ever, we  cannot  generalize  that  debugging  is  more  economical  because  a 
decision  depends  upon  the  magnitude  of  the  various  parameters  such  as  de- 
velopment cost,  penalty  charges,  etc.  The  equations  discussed  are,  how- 
ever, applicable  to  all  programs. 


8=2. 


Asymptote 


Debugging 
Reg 


50  70  90  100  130  150  170  190  210 

£ 

Number  of  man-month  c0"* 

£ 

— = Rewriting  cost/Debugging  Cost  per  man-month. 


Fig.  6.  1 Demarcation  between  debugging  and  rewriting  regions' 
(see  Eq.  (6.  7)) 


CHAPTER  7 


CONCLUSION 


7.  1 Summary 

The  development  of  an  error  model  which  accounted  for  error  growth 
progressed  through  several  stages,  and  culminated  in  the  complex  model 
developed  in  Chapter  5.  At  this  point  we  are  unable  to  justify  the  validity 
of  those  models  because  relevant  experimental  data  is  unavailable.  How- 
ever, basic  assumptions  and  overall  form  of  the  results  seem  realistic. 

The  model  development  led  to  the  analysis  of  three  cases.  Assignment  of 
insufficiently  experienced  debuggers  results  in  a situation  as  depicted  in 
Case  1 while  a contrast  to  this  is  observed  (Case  2)  if  superior  debuggers 
are  assigned  to  the  same  job.  Very  often  programmers  work  on  more  than 
one  project  at  a time  and  once  the  errors  in  one  project  are  well  under  con- 
trol the  superior  debuggers  are  assigned  a new  task  which  may  subsequently 
result  in  an  error  buildup,  and  this  is  explained  by  Case  3. 

7.  2 Suggestions  for  Further  Work 

Having  evolved  reasonable  error  models,  the  next  step  is  to  evaluate 
the  various  parameters  of  the  models,  and  test  the  validity  of  the  model  as 
a prediction  test.  In  order  to  reduce  the  mathematical  complexity,  the 
change  of  manpower  in  all  the  mode's  has  been  assumed  to  be  abrupt.  In 
practice  the  change  is  gradual. 

Moreover  the  growth-decay  parameters  (a's  and  k's)  are  complex 
functions  of  the  debugging  time  t,  manpower  variation  and  rate  of  change 
of  errors  in  the  program.  In  order  to  formulate  these  functions  it  is  neces- 
sary to  study  the  changing  manpower  and  the  rate  of  error  removal  at  every 
instant  of  debugging  time  in  many  projects.  Another  method  of  developing 
these  functions  is  to  measure  the  above  parameters  of  individual  program- 
mers. Once  these  are  available  for  every  programmer,  the  parameters 
for  the  team  could  be  established  by  including  a mutual  interaction  coeffi- 
cient (a  factor  due  to  coordination  problems  between  programmers).  Once 
these  functions  for  the  team  are  available,  the  error  equations  discussed 
in  Chapter  5 could  be  applied  to  obtain  a practical  estimate  of  debugging  ef- 
fort required  for  any  project. 
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APPENDIX  I 


A summary  of  the  basic  models  and  assumptions  of  Chapters  4 and  5 
appear  in  Table  A-l  below. 

TABLE  A-l  (Summary  of  Error  Models) 


BASIS  EQUATION  Eq.  (4.  3) 


dn(r)  _ 
dr 


rg(T)  - rc(T) 


CASE 


1.  Gene  ration  and 
Correction 
Proportional  to 
Detection 

rg(T ) = oil 3rd(r) 


n(r  = 0)  = nQ 


EQUATION 


Mr)  - j3(o"l  )rd(r) 


rc(T)=  ^rd(T) 


2.  No  generation 

rg(r)  = 0 A(T)=-)3ro 

rc(T)=  ^rd(T) 

["Correction  ~ Detection! 
Detections  Constant 


3.  No  generation 

rg(r)=  0 n(r)  = -/Sl^nfr) 

rc(T)=prd(T) 

rd(r)=  Ktn(r) 

[Correction  ~ Detection 
Detection"  Error  Present 


SOLUTION 


If  o < 1 

n(T)  is  a decreasing 
function 

If  a > 1 

n(T)  is  an  increasing 
function 


n(T  ) = no-(j3rQ)T 
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CASE 

4.  Generation 

Proportional  to 
Product  of  Errors 
Present  and 
Detection 


EQUATION 


r (t)  = a rd(r)  n(r)  n(-r)  =[an(T)-b]rd(<r) 


rc(T)  = b rd(T) 


Correction 
Proportional  to 
[Detection 


Generation 
Proportional  to 
Number  of  Er- 
rors Present 
and  Correction 
is  either  Man- 
power or  Detec- 
tion limited. 

*g(T ) = n(T ) 


for 

n(T)>  nj 


rc(T)= 


k^ntr)  for 
n(T ) < nj 


For  r ,(t)=  const.  = r 
a o 

n(T)=  fan(r)-b]r 


n (t)=  "kj  +Sj  n(T) 
for  n(r)  > n. 


n(T)=  -k2n(T) 

+ a^fr) 
for  n(r)  < n^ 


SOLUTION 


ar  t 

n(r)=  (nQ-b/a)e  ° +b/a 

If  n < b/a  then  n(r)  is 
an  ftverted  exponential 


If  n > b/a  then  n(r)  is 
a growing  exponential 


n(r)  > nt 

a . t 

n(T>=(no-k1/a1)e  +kJ/a1 

(same  form  as  Case  4) 

n(T)  < nj 

n(Ty=n(exp[(a<-k2)(T-Tt  )1 

(i)  If  1 < k2/a j , then 

n(T)  decays  exponen- 
tially as  shown  in 
Fig.  5.  lb 

(ii)  If  1 >k2/a  , then 
n(r)  oscillates  as 
shown  in  Fig.  5.  1 c. 
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APPENDIX  II 


START 


no’  nl’  n2’  n3 

ai*  ar  kt*  kr  k? 

kg,  CASE,  DT, 

DGRAPHT,  FIN 


YES 

CASE  1 |PAGE  53 
ACCEPTS 

no*  ni«  n2» 

a j , kl#  k2* 

DT,  DGRAPHT, 
FIN  AND  COM- 
PUTES n,  n in. 


CASE=  1 


CASE=  2 


CASE  2JPAGE  55^ 
ACCEPTS 

"o’  nr  n2*  ai 
k . kg,  DT, 

DGRAPHT, 

FIN  AND  COM- 
PUTES n,  n «.n 


CASE  3 pAGE  5? 
ACCEPTS  no,  ly 

Hgi  ® jt  kj,  kg, 

kg,  DT,  DGRAPHT, 

FIN  AND  COM- 
PUTES n,  n fc  n. 


n,  nc  & nt  ARE  (0:500)  ARRAYS 

DGRAPHT=  INTERVAL  BETWEEN 
PLOTTED  POINTS. 
DEFAULTS 

DT=  REGULATES  THE  TIME  INTERVAL 
IN  WHICH  THE  EQUATIONS  ARE 
EVALUATED.  THE  SMALLER  THE 
DT  THE  MORE  PRONOUNCED  THE 
TRANSITIONS  WILL  BE. FOR  BEST 
RESULTS 
DT*  DGRAPHT/l  0 

FIN=THE  NUMBER  OF  POINTS  TO  BE 
PLOTTED. 

DEFAULT*  50 

CASE* EITHER  1 OR  2 OR  3 DEPENDING 
UPON  THE  PARAMETERS 


THE  PROGRAM  STOPS  ON 
THE  ENDFILE  CONDITION 


Fig.  A 2.  I The  System  Flowchart 
Note : 

The  ofige  numbers  adjacent  to  each 
box  inJicute  the  location  of  the  flow- 
chart portraying  the  case  in  detail. 


PRINTGRAPH 


PLOTS  n,  n v n, 
c t 

AS  A FUNCTION 
OF  DEBUGGING 
TIME  t 
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ILLEGAL  DATA 
VALUES 


n(l)  = (n0-k|/0|)exp(o,r)+k|/0| 

neUt)  = kir 
nt(fi)  = nc(i)+n(A) 


THE  NO  BRANCH  IS 
TRAVERSED  WHEN  THE 
FIRST  TRANSITION 
OCCURS  AT  n' 


n (fl)  = ( n-  k'i/ai)  exp  [d,(r  - t')] + kVa", 
nc(fi)  = k|T+k^(r- r') 
nt  (fi)  = n(i)+nc(G) 


THE  NO  BRANCH  IS 
TRAVERSED  WHEN  THE 
SECOND  TRANSITION 
OCCURS  AT  n, 


n(Jl)  = n(  exp[(a,-k2)(T-Ti)] 

ncUO  = kir'+  ki(n  - r ) + k*  n(  /(a'i-k2){exp[(ai- kzKr-  n)]- 1 } 
n»(Q)=  n(fl)+nc(fi) 


RETURN 
t'  ANDt, 


Fig.  A 2.  3 Part  2 of  the  flowchart  for  CASE  1 


5 


Fig.  A2.  6 Part  1 of  the  flowchart  for  CASE  3 


nt(Q)  = n(!)+nc(Q) 


Fig.  A 2.  7 Part  2 of  the  flowchart  for  CASF.  3 
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0 


PLOTS  N,  NC  Si  NT 
AS  A FUNCTION  OF  T 


RETURN 
TPRIME,  T I 


Fig.  A 2.  10  Part  2 of  the  flowchart 
for  CASE  i which  is  compatible 
with  the  computer  program 
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TABLE  A-2 


CORRESPONDENCE  BETWEEN  ACTUAL  PARAMETERS 
AND  PROGRAM  PARAMETERS 

The  flowcharts  of  Figs.  A2.  1 to  A2.  8 summarize  the  text  in  this  report 
(i.  e.  the  parameters  are  the  same  as  in  the  text).  The  program  is  written 
in  the  upper  case  alphabet  since  the  lower  case  alphabet  is  evidently  not 
available.  The  correspondence  between  the  actual  parameters  and  those  in 
the  computer  program  is  as  follows: 

ACTUAL  PARAMETERS  PROGRAM  PARAMETERS 


n 

NO 

o 

n» 

NP 

nl 

Nl 

n2 

N2 

n3 

N3 

n 

c 

NC 

nt 

NT 

ai 

AI 

ai 

A1P 

ki 

KI 

ki 

KIP 

k2 

K2 

k3 

K3 

T' 

TPRIME 

T1 

T 1 

t2 

T2 

T3 

T3 

A flowchart  compatible  with  the  program  will  require  a much  greater 
level  of  detail.  Figs.  A 2.  9 and  A2.  10  present  such  a flowchart  for  case  1. 
The  flowcharts  for  the  remaining  cases  are  analogous  and  are  not  included. 
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( STRI N GRANGE  * SUB SCR  I PTR ANGE  ) ! 

HOOELS:  PROCEDURE  OPTIONS  CHAIN); 

/*  EXPLANATIONS  OF  DATA  VARIABLES 


INPUT  VARIABLES 
CASE1 

NOtNP»Nl»Ai»AlP,Klt 
K 1 P» K2  *DT tDGRAPHT  » FI  N 


CASE  2 

NO*Nlt A1»K1«K2 
CASE3 

NO»NlfN2tN3»AlfKlfK2»K3 

DGRAPHT 


DT 


FIN 


THE  CORRESPONDENCE  BETWEEN 
THESE  VARIABLES  ANO  THOSE 
IN  THE  TEXT  (WHICH  ARE 
WRITTEN  IN  LOWER  CASE) 

FOR  ALL  CASES  IS  SHOWN  IN 
TABLE  A-2  ON  PAGE  62. 


INTERVAL  BETWEEN  PLOTTED 
POINTS.  DEFAULT  = 1 

REGULATES  THE  TIME  INTERVAL 
IN  WHICH  THE  EQUATIONS  ARE 
EVALUATED.  THE  SMALLER  THE 
VALUE  OF  DT  THE  CLOSER  THE 
TRANSITIONS  WILL  BE.  FOR 
BEST  RESULTS  DT=DGRAPHT/ 10. 

THE  NUMBER  OF  POINTS  TO  BE 
PLOTTED.  DEFAULT  = 50. 


**********  EXAMPLES  OF  DATA  CARDS  *********************** 

CASE=2 » NO=iOO,  Kl=10»  K2=.2,  Nl=25,  Al=.0665  ; 

CA SE  = 3 1 NO=iO-t  Kl-10 » Al=.026,  Nl  = 30,  K2  = .01»  N2*40t 
N3=20 * K3*. 15  J 

********************************************************  */ 
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'■ 


DECLARE 


DECLARE 


» '*w  r *»'  r ii«  r A 1 f A 1 P , !■  * * >1  * I * p H ^ 7 ' * 7 n^i 
FLOAT  INITIAL  10), 

(N_TA8,  NC_TAB,  NT .TAB  ) (0:5001  FLOAT!  16  ), 
(T,  TPRIME,  Tl,  T2,  T3,  N,  NC,  NT)  FLOAT  (16) 
INITIAL  (OEO) ; 

( COUNT,  LASTN,  DGRAPHT,  DT  , FIN,  PLOT.TIMEI 
FLOAT,  l FIXED  BIN  (31), 

STAGE  FIXED  BINARY  (311  INITIAL  (l)J 


PLOT.TI ME  I 


/*  PLOT.TIME  IS  THE  INSTANT  OF  TIME  AT  WHICH  THE  FUNCTION 
IS  PLOTTED,  WHEREAS  T IS  THE  INSTANT  OF  TIME  AT  WHICH 
THE  EQUATIONS  ARE  COMPUTED.  THE  TIME  INTERVAL  IN  WHICH 
THE  EQUATIONS  ARE  COMPUTED  IS  MUCH  SMALLER  THAN  THE 
INTERVAL  BETWEEN  THE  PLOTTED  POINTS  ( TEN  POINTS  ARE 
COMPUTED,  AND  ONLY  CNE  PLOTTED).  T«  PLOT.TIME  IS 
DESIRED  BECAUSE  A CONTINUOUS  CHANGE  OF  THE  VARIABLES 
N,  NC  AND  NT  IS  AVAILABLE  (IN  THE  ASSUMED  INPUT  DATA). 

A SMALL  T IS  EQUIVALENT  TO  A DAY-TO-DAY  PROGRESS  IN  A 
REAL-LIFE  SITUATION,  WHILE  A LARGE  PLOT.TI ME  IS  EQUIVALENT 
TO  A CO-ORDINATE  IN  A PERFORMANCE  CHART  OVER  A LONG 
PERIOD,  SAY  ONE  YEAR.  THE  RECORDING  OF  THE  RESULTS, 
HOWEVER,  MAY  TAKE  PLACE  EVERY  15  DAYS.  */ 


1 


ON  ENDFIIE  ( SYS  I N I BEGIN;  ? 

PUT  PAGE  EDIT  ('END  OF  DATA  ENCOUNTERED.  •,  • IF  ANY  'll 
•DATA  SETS  SEEN  TO  HAVE  BEEN  SKIPPED,  CHECK  TO  SEE  IF  YOU* 
||  • PUT  IN  THE  SEMICOLON*,  • ******TERMINAT I NG  RUN  **** 

•)  CCOL(l),A); 

stop; 

end; 

ON  NAME  (SYSIN)  BEGIN; 

PUT  PAGE  EDIT  (•  ERROR  *****  ONE  OF  THE  INPUT  DATA  ITEMS  • 
II  MS  NOT  AS  EXPECT60.  THE  ONLY  LEGAL  DATA  ITEMS  ARE  :•, 

* NO,  NP*  Nl,  N2»  N3,  Al,  A1P,  Kl,  KIP,  K2 , K3,  DT , FIN,  • 
I I *DGRAPHT • , 

* THE  LAST  THREE  BEING  OPTIONAL*.  'PROBABLE  CAUSE  IS*  II 

* KEYPUNCH  ERROR  IN  PUNCHING  THE  DATA*,  • THE  PART  WHICH  • 
I I 'CAUSED  THE  TROUBLE  IS: * I I DATAFI ELD, 

. *****  TERMINATING  RUN  ****♦•)  ( A, SKIP); 

STOP; 

ENO; 

ON  ERROR  SNAP  BEGIN; 

ON  ERROR  SYSTEM; 

PUT  SKIP  (4)  LIST  (•  AN  INTERNAL  PROGRAM  ERROR  HAS  'll 
•OCCURED.  PLEASE  SHOW  THIS  PRINTOUT  TO  S.  NATARAJANM; 

PUT  SKIP  LIST  ( *ONCOOE=* , ONCOOE); 

PUT  SKIP  (41  DATA; 

STOP; 

END; 


/*  INITIALIZATIONS  */ 

T=o;  f i n®50  ; dt=ie-i;  dgraphtm; 

DO  WHILE  (*I'B); 

GET  DATA  <NO,NP,Nl,N2, N3,  Al , A IP ,K 1 ,K IP ,K2 , K3 , DT .DGRAPHT, 
CASE, FIN); 

STAGE*0; 

/*  STAGE=0  INDICATES  WE  ARE  BEFORE  THE  FIRST  TRANSITION 
STAGE*1  INDICATES  AFTER  FIRST  TRANSITION 

STAGE=2  INDICATES  AFTER  SECOND  TRANSITION  */ 

PLOT_TI ME*OGRAPHT ; 

N_TAB ( 0) *N0; 

NC_TAB(0)*0  ; 

NT_TAB (0 ) *N_T AB( 0)  ; 

LA  STN=N_T  AB( 0 ) ; 


/*  LASTN  IS  THE  PREVIOUS  VALUE  OF  N */ 
IF  CASE*1  THEN  CALL  CASE1  ; 

ELSE  IF  CASE s2  THEN  CALL  CASE2; 

ELSE  CALL  CASE3; 


end; 
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CASEls  PROC; 

CGUNT=OE  0; 

N_  TAB  = JEO;  NC_TA8-0E0  » NT_TAB=OEO ; 

PUT  PAGE  EDIT  ('CASE  l • IlCOL  (44 ) ,A ) ; 

PUT  SKIP  (3); 

PUT  EOIT  ( 'NO  *' » AO , ' NP  =',NP,'N1  =',N1) 

(COL (14) ,A,CUL(19),F(3) , COL (38) ,A,C0L(43) »F(3)  , 

COL ( 63) ,A,C0L(68) ,F(2I  ) 

CA1  = ' , A1 , * A IP  =',A1P,'K1  =',K1) 

(COL (14) ,A,C0L(19),F(5,3) ,COL ( 38 ) , A, COL ( 44) ,F ( 6,4 ) , 
COL (63) ,A,COL (68  > ,F( 2 ) ) 

( • KIP  *',K1P,«K2  =',K2,'DT  =',DT) 

( COL( 14) , A ,COL( 20 ) , F( 4 , 1) , COL ( 38 ) , A, COL (43 ) ,F( 5,3 ) , 
COL (63), A, COL (68) ,F(5,3)) 

( ' DGRAPHT  =• .DGRAPHT, ' F IN  =',FIN) 

( COL ( 14) , A ,COL( 24 ) , F ( 1 ) ,COL ( 3 8) , A , COL  ( 44) , F ( 2 ) ) ; 

PUT  SKIP  (6) 5 

IF  (AL<  = 0)  | (N0<=KI/A1)  I (A1P  = 0)  | ( NP>=K1P/A1P) 

THEN  GO  TO  ERROR  ; 

GO  TO  RESUME? 

ERf*OR:  PUT  SKIP  LIST  (•  ILLEGAL  DATA  VALUES,  SKIPPING  SET'); 

return; 

RESUME: 

LOOP:  DO  T*  OT  TO  FIN  BY  DT; 

/*  COMPUTE  THE  EQUATIONS  */ 

IF  STAGE  *0  THEN  DO; 

N= ( N0-K1 /A1 ) * EXP(AL*T)+  Kl/Al  ; 

NC=  K1*T; 

END; 

FLSE  IF  STAGE=l  THEN  DO; 

N= (NP— K1P/A1P)  * EXP(AIP*(T~TPRIME»)  ♦ KIP/A1P; 
NC=Ki*TPRIME  ♦ K1P*(T-TPRIME); 

END; 

ELSE  DO; 

N=N i*EXP ( ( A IP-K2) * (T-T 1 ) ) ; 

NC=K1*TPRIME  ♦ KLP*(T1-TPRIME)  ♦ ( K2*N l ) / (K2-A IP  ) * 

I 1-EXP( (A1P-K2)*(T-T1  )))  ; 

END; 
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/*  IN  ANY  EVENT  */  NT  = N ♦ NC i 

IF  T>PLOT_TIME  THEN  00;  /*  IT'S  TIME  TO  RECORD  ANOTHER 

SET  OF  POINTS  FOR  LATER 
GRAPHING  */ 

CQUNT=COUNT  ♦ I; 

N.TABICOUNTI  = N; 

NC_TAB( COUNT)  = NC ; 

NT_T  AB (COUNT ) = NT; 

PLOT_TIME  * PLOTJTIME  ♦ DGRAPHT ; 

END; 

IF  STAGE  = 0 THEN  IF  I N-NP ) *( LAS TN-NP ) <*0E0  THEN  DO; 

/*  THE  ERRORS  HAVE  INCREASED  TO  N'  WHICH  CORRESPONDS  TO 
THE  FIRST  TRANSITION  IN  THE  ERROR  EQUATION  . */ 

TPRIME=T; 

STAGE  = 1; 

FND; 

ELSE; 

ELSE  IF  STAGE  = I THEN  IF  (N-Nl)  * < LASTN-N 1 ) <=0E0  THEN  DO; 
/*  THF  ERRORS  HAVE  DECREASED  TO  N1  WHICH  CORRESPONDS  TO 
THE  SECOND  TRANSITION  IN  THE  ERROR  EQUATION,  */ 

STAGE  = 2; 

Tl=T; 

END; 

LASTN=N; 

END  LOOP; 

CALL  printgraph; 

PUT  SKIP  DATA  { TPRIME  • Tl); 


cun  r acci ; 


■* 


CASE2JPR0C; 

count*o; 

N_TAB«OEO;  NC_TAB*OE  0 ; NT_TAB*OEO; 

PUT  PAGE  EOI I ( 'CASE  2 • I ( COL ( 44) VA ) ; 

PUT  SKlPC3)i 

PUT  EDIT  I * NO  *',NO,'Nl  *»,N1,*AI  *',A1) 

(C0L(14)»A,COL(19),F(3) ,COL(38) , A , COL ( 4 3) , F ( 2 ) , 

COL (63) » At COL (68 )*F(6»4)) 

CK1  * ' « Kl y ' K2  * ' yK2  y ' DT  *',DT) 

(COL (141 »A,COL( 19),F(2),COL(3B)t A, COL (43) »F(5f3), 

COL ( 63 ) « A t COL (68) »F  ( 5 » 3 ) ) 

('FIN  »• #FIN» 'OGRAPHT  *',OGRAPHT) 

(COL (14) ,A,C0L(20),F(2) ,COL (38) , A,C0L(48) ,F(1)  ); 

PUT  SKIP  (6); 

LOOP:  00  T*  OT  TO  FIN  BY  DT; 

/*  COMPUTE  THE  EQUATIONS  */ 

IF  STAGE  = 0 THEN  DO; 

N= ( NO-Kl/Al )*EXP(A1*T)  ♦ Kl/AIS 
NC  * K1*T; 

e.mo; 

ELSE  DO; 

N=Ni*EXP( ( A1-K2) * ( T-T 1)1; 

NC*Kl*Tl  ♦ (K2*N1)/(K2-A1)*( 1E0  - EXP( ( A1-K2 )*( T - Ti))); 
END; 

NT=N  ♦ NC; 

IF  T>PLOT_TI ME  THEN  DO;  /*  IT'S  TIME  TO  RECORD  ANOTHER 

SET  OF  POINTS  FOR  LATER 
GRAPHING  */ 

COUNT*COUNT+l; 

N_TAB( COUNT)  *N; 

NC_TAB( COUNT )*NC; 

NT_T  AB( COUNT ) *NT ; 

PLOT_TIME*PLOT_TIME+DGRAPHT; 

end; 

IF  STAGE-0  THEN  IF  ( N- M )* ( L ASTN-N1 ) <*0E0  THEN  DO; 

/*  THE  ERRORS  HAVE  DECREASED  TO  N1  WHICH  CORRESPONDS  TO 
THE  FIRST  TRANSITION  IN  THE  ERROR  EQUATION,  */ 

T1*T ; 

STAGE* l; 

end; 
lastn*n; 
end  loop; 

CALL  PRINTGRAPH; 

PUT  SKIP  DATA(Ti); 

END  CASE2; 
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FLOAT  INIT(OEO) 


PUT  SKIP 
PUT  EOIT 


CASE3JPROC; 

OECLARE  ( NCT2.  /*  *NC(T2)  ♦ / 

NCT3  /**NC(T3)  */) 

L0UNT*0; 

N_TAB*OEO;  NC_TAB«OEO;  NT_TAB=OEO; 

PUT  PAGE  EOIT  I'CASE  3* ) (COL (441 »A) ; 

(3); 

I • NO  *• » NO. • N l =*,Nl,»N2  ='.N2) 

(COL  I 14) .A . COK 19 ) . F ( 3 ) .COL (38). A. COL (43) »F(2) 
COL ( 63) «AfCOL(68) ,F(2) ) 

(»N3  *' »N3  » • A l =',A1,'K1  =*,K1) 

(COL (14) » A *COL( 19 ) * F ( 2 ) ,COL(38) » A » COL( 43) * F( 6 ♦ 
COL (63) » A,CUL(68),F(2) ) 

(«K2  *• » K2» ' K3  *»,K3,*OT  =*,OT) 
lC0L(l4),AfC0L(19),F<6,4),C0L(38),A,C0L(43) ,F( 
COL (63) , A, COL (68) ,F(5,3I) 

(•FIN  ■• .FIN, 'DGRAPHT  = ' » DGRAPHT ) 

(COL (14) , A ,COL( 20 ) » F ( 2 ) .COL (38) , A , COL< 48 ) . F( I ) 

PUT  SKIP  (6)J 


LOOP:  DO  T=  OT  TO  FIN  BY  OT; 

/*  COMPUTE  THE  EQUATIONS 
IF  STAGE  *0  THEN  00; 

N*(N0-KI/A1 )*  EXP ( AI*T ) ♦ Kl/Al* 

NC=K 1*T ; 

end; 

ELSE  IF  STAGE  * 1 THEN  00; 

N=Nl*EXP ( ( AI-K2 )*( T~T1 ) ) « 

NC*  (K2*N1)/(A1-K2)*(EXP( ( AI -K2 )*( T-Tl ) )-lE0)+Kl*Tl 
END; 

ELSE  IF  STAGE=2  THEN  DO; 

N=(N2-Kl/AL)*EXP( A1*(T-T2) ) ♦Kl/Al ; 
NC=NCT2+K1*(T-T2); 

END; 


4). 
5.3)  . 
); 

*/ 


ELSE  IF  ST AGE  = 3 THEN  DO; 

N=N3*EXP(CAI-K3)*IT-T3) ); 

NC=(K3*N3)/(K3-Al)*U-EXP( ( A 1-K3 ) * ( T-T3 ) ) H-NCT3J 
END; 

nt=nc*n; 

IF  T>PLOT_TI ME  THEN  DO;  /*  IT'S  TIME  TO  RECORD  ANOTHER 

SET  OF  POINTS  FOR  LATER 
GRAPHING  */ 

COUNT*COUNT»l; 

N_TABICOUNT ) =N; 

NC_T  AB (COUNT ) =NC • 

NT_TA6( COUNT) =NT ; 

plot_time=plot_time+cgrapht; 

END; 

IF  STAGE*0  THEN  IF  ( N-Nl ) * ( LASTN-N  1 K=OEO  THEN  DO; 

/*  THE  ERRORS  HAVE  DECREASED  TO  N1  WHICH  CORRESPONDS  TO 
THE  FIRST  TRANSITION  IN  THE  ERROR  EQUATION,  */ 

TI  = T ; 

stage=i; 

END; 

else; 

ELSE  IF  STAGE=I  THEN  IF  (N-N2)*(LASTN-N2)<=0E0  then  do; 

/*  THE  ERRORS  HAVE  UNFORTUNATELY  INCREASED  TO  N2  WHICH 
CORRESPONDS  TO  THE  SECOND  TRANSITION  IN  THE  ERROR 
EQUATION,  */ 

T2=T ; 

NCT2*NC; 

ST  AGE=2 ; 

END; 

ELSE; 

ELSE  IF  ST  AGE*2  THEN  IF  ( N-N3 ) * UASTN-N3  )<  = OEO  THEN  DO; 

/*  THE  ERRORS  HAVE  NOW  DECREASED  TO  N3  WHICH  CORRESPONDS 
TO  THE  THIRD  TRANSITION  IN  THE  ERROR  EQUATION.  */ 

T3  = T; 

NCT3=NC; 

ST  AGE®3; 

end; 

lastn=n; 
end  loop; 

CALL  PRINTGRAPH; 

PUT  SKIP  DATA! T I » T2  » T 3 I ; 

END  CASE3; 
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(SIZE): 

PRINTER APHSPROCJ 

DECLARE  I ♦ REOUCTION_FACTOR  FLOAT; 

DECLARE  BIG; 

DECLARE  PRINTLINE  CHAR(80); 

DECLARE  ( FLOOR tSUBSTR ) BUILTIN; 

/*  FIND  MAX  OF  ARRAY  NT_T AB  */ 

BIG»0; 

DO  I =0  TO  FLOOR! FIN/CGRAPHTI  ; 

IF  NT_TA8( I )>8IG  THEN  8IG*NT_TAB( I ) ; 

END; 

ON  SIZE  SYSTEM; 

ON  SUBSCRIPTRANGE  SNAP  BEGIN;  PUT  OATA;  STOP;  ENO; 

ON  STRINGRANGE  SNAP  BEGIN;  PUT  OATA;  STOP;  END; 

R EOUC T I ON_F ACTOR  ®50/BIG; 

(SIZE):  PUT  EDIT ( ( I /REDUCT I 0N_ FACTOR 

DO  1=  0 TO  IDO  BY  10  ) ) (COL( 14) , F( 7,2 ) , 10F(10t2)); 

PUT  EDIT  ( (6)'-.'  I I • | '»  ( (9)  •-»'  | | • | • DO  I = l TO  10)) 
(C0L(14).A*10A(10)); 

PRINTLINE®'  •; 

SUBSTR! PRINTLINE* REDUCT  1 0N_FACT0R*N_TAB(0) ♦1,1)='N» ; 
SUBSTR(PRINTLINE,RE0UCTI0N_FACT0R*NC_TAB(0)+1,1 )='C'; 
SUBSTR  (PRINTLINE  tREDUCTI ON_F AC TOR*NT_T  AB(0)+ltl  >='T'; 

PUT  SKIPIO)  EDITIPRINTLINE) (C0L(20),A) ; 

DO  1=1  TO  COUNT; 

PRINTLINE®'  •; 

SUBSTR! PR INTLINEtltl)*'  I ' ; 

SUBSTR ( PR INTL INE  t REDUCT ION_FACT  OR*N_T  AB ( I )+l, 1)®'  N' ; 
SUBSTR! PRINTLI NE, REDUCT ION.FACT OR *NC_TAB( I )+ltl)»'C'; 
SUBSTR! PRINTLINE  tREDUCTI ON_F ACT  OR *NT_T  AB( I 1*1,1 )®'T' ; 

IF  MOD ( 1 1 10 )=0  THEN  PUT  EDI T U *DGRAPHT, PR  I NTL IN E) 

( COL ( 9 ) t F ( 10 1 2 ) • X ( 1 ) * A ) ; 

ELSE 

PUT  EDITIPRINTLINE) (C0L(20), A); 

END; 

PUT  PAGE; 

PUT  EDIT  ('N't'NC't'NT') 

(COL(IO) ,3A( 10) ) 

( (N_TAB ( KK ) t NC_T AB( KK ) , NT_TAB ( KK)  DO  KK=0  TO  COUNT)) 

( COL (8)t3F(10f2))  ; 

RETURN; 

ENO  PKINTGRAPH; 

END  MODELS  ; 
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MAN  MONTHS  OF  DEBUGGING 


CASE  1 


NO  * 100 
A1  = 0.125 
KIP  = 12.5 
OGRAPHT  = l 


NP  * 125 
A 1 P = 0.0350 
K2  = 0.150 
FIN  = 50 


N 1 * 25 
K 1 = 10 
DT  = 0.100 


NUMBER  OF  ERRORS 


10.00 


20.00 


Fig.  A2.  11  Computer  Printout 
for  Case  1 
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MAN  MONTHS  OF  DEBUGGING 


CASE  2 


NO  = 100 
K 1 = 10 
FIN  = 50 


Nl  = 25 
K 2 = 0.150 
DGRAPHT  = 1 


A1  » 0.0250 
OT  * 0.100 


NUMBER  OF  ERRORS 


0.00 


10.00 


20.00 


23.99 


47.99 

»-» “i-i-i  | - 


71.98 

» -i-i -i-i  | - 


95.97 

i -i-i  -I  -I  1 1 1 - 

N T 


119.97 

in  hi  | * 


N 

N 

30.00  N 
N 
N 
N 
N 


Fig.  A2.  12  Computer  Printout 
for  Case  2 
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MAN  MONTHS  OF  DEBUGGING 


CASE  3 


NO  = 

100 

Nl  * 

25 

N2 

S 

28 

N3  = 

15 

A1  = 

0.0250 

Kl 

S 

10 

K2  = 

0.0050 

K3  = 

0.150 

0T 

S 

0.100 

FIN  = 

* 50 

OGRAPHT  = l 

NUMBER  OF 

ERRORS 

0, 

.00 

24.54  49.08 

73.62 

98.16 

122 

.71 

-nn-i 

-1 | -.-.“I  IT'''**-'  | "» 
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Fig.  A2.  13  Computer  Printout 
for  Case  3 
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METRIC  SYSTEM 


* 


i 


BASE  UNITS: 


Quantity 

Unit 

SI  Symbol 

Formula 

length 

metre 

m 

mass 

kilogram 

kg 

time 

second 

a 

electric  current 

ampere 

A 

thermodynamic  temperature 

kelvin 

K 

amount  of  substance 

mole 

mol 

luminous  intensity 

candela 

cd 

SUPPLEMENTARY  UNITS: 

plane  angle 

radian 

rad 

solid  angle 

steradian 

sr 

... 

DERIVED  UNITS: 

Acceleration 

metre  per  second  squared 

m/s 

activity  (of  a radioactive  source) 

disintegration  per  second 

(disintegration  Vs 

angular  acceleration 

radian  per  second  squared 

rad/s 

angular  velocity 

radian  per  second 

rad/s 

area 

square  metre 

m 

density 

kilogram  per  cubic  metre 

kg'm 

electric  capacitance 

farad 

F 

A-s/V 

electrical  conductance 

siemens 

S 

A/V 

electric  field  strength 

volt  per  metre 

V/m 

electric  inductance 

henry 

H 

V-s/A 

electric  potential  difference 

volt 

V 

W/A 

electric  resistance 

ohm 

V/A 

electromotive  force 

volt 

V 

WIA 

energy 

joule 

1 

N-m 

entropy 

joule  per  kelvin 

J/K 

force 

newton 

N 

kg-m/s 

frequency 

hertz 

Hz 

(cycle  Vs 

illuminance 

lux 

lx 

ltn/m 

luminance 

candela  per  square  metre 

... 

cd/m 

luminous  flux 

lumen 

lm 

cd-sr 

magnetic  field  strength 

ampere  per  metre 

A/m 

magnetic  flux 

weber 

Wb 

V-s 

magnetic  flux  density 

tesla 

T 

Wb/m 

magnetomotive  force 

ampere 

A 

power 

watt 

W 

v* 

pressure 

pascal 

Pa 

N/m 

quantity  of  electricity 

coulomb 

C 

A-s 

quantity  of  heat 

joule 

1 

N-m 

radiant  intensity 

watt  per  steradian 

W/sr 

specific  heat 

joule  per  kilogram-kelvin 

J/kg-K 

stress 

pascal 

Pa 

N/m 

thermal  conductivity 

watt  per  metre-kelvin 

W/m-K 

velocity 

metre  per  second 

m/s 

viscosity,  dynamic 

pascal-second 

Pa-s 

viscosity,  kinematic 

square  metre  per  second 

m/s 

voltage 

volt 

V 

W/A 

volume 

cubic  metre 

m 

wavenumber 

reciprocal  metre 

(waveVm 

work 

joule 

i 

N-m 

SI  PREFIXES: 


Multiplication  Factors 

Prefix 

SI  Symbol 

1 000  000  000  000  = 10” 

tera 

T 

1 000  000  000  = 10’ 

gig* 

C 

1 000  000  = 10* 

mega 

M 

1 000  = 10’ 

kilo 

k 

100  = 10> 

hecto* 

h 

10  = 10' 

delta* 

da 

0.1  = 10-» 

decl* 

d 

0.01  = 10~» 

cent!  * 

c 

0001  = 10-' 

mllll 

m 

0.000  001  = 10-  * 

micro 

M 

0.000  000  001  = 10- * 

nano 

n 

0.000  000  000  001  = 10- 11 

pico 

P 

0.000  000  000(100  001  = 10-" 

fern  to 

f 

0.000  000  000  (KM)  0(H)  001  =-•  10'  '• 

atto 

a 

* To  be  avoided  where  possible. 
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